Paradigm RETH just released production read 1.0.0. QuickNode is ready for us to consume the production-ready dedicated RETH cluster as well. From Uniswap perspective, the migration from GETH to RETH boils to two considerations:

1. Can we rely on the RPC provider to do automatic failover for us? Meanwhile QuickNode could, Uniswap has no way to know when that happens. Also RETH is newly productionized, it's better if the clients do the output comparisons ourselves. Hence this PR aims to compare the GETH vs RETH RPC responses ourselves.
2. Can we confidently live migrate from GETH to RETH at Uniswap scale? Since RETH is only ready on L1, we are only speaking the Uniswap RPC volume on L1:
   a. eth_call is about 1.4k RPS
   b. eth_getBlockNumber is about 345 RPS
   c. ethers js v5.5 style send, which can be eth_call/eth_getBlockNumber/eth_feeHistory/eth_estimateGas RPC. Those calls are in additional to the RPC calls in (a) and (b):

We have done the Perf testing using the Paradigm Flood, at above mentioned scale, and can see QuickNode RETH can cut QuickNode GETH latencies by half in P50, P90, and P99:

With this perf testing, we will implement a live migration in a separate PR, such that it allows us to migrate from GETH to RETH at designated percent as we want, i.e. 100% GETH 0% RETH -> 99% GETH 1% RETH -> 95% GETH 5% RETH -> ... -> 0% GETH 100% RETH.

Client output comparison implementation correctness wise, I've covered with complete unit test coverage, as well as run npm run test:e2e against my local AWS routing-api endpoint:

Due to low traffic volume, I can only verify the basic RPC outputs matching on my local. I will have to merge to prod to see the comparison at a subset of prod traffic volume (sampling at 5%).